Add availability API for addons #6140
Conversation
mdegat01
added
missing-documentation
mdegat01
removed
missing-documentation
There was a problem hiding this comment.
Pull Request Overview
This PR adds a new API endpoint to check add-on availability for the current system. The endpoint validates whether an add-on can be installed or updated based on architecture compatibility, machine type support, and Home Assistant version requirements.
Key Changes
- Added
/store/addons/{addon}/availabilityGET endpoint that validates add-on compatibility - Implemented comprehensive test coverage for various availability scenarios including architecture mismatches, machine incompatibility, and version requirements
- Integrated the new endpoint into the API routing system
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| supervisor/api/store.py | Adds the new availability endpoint handler that extracts the addon and validates its availability |
| supervisor/api/init.py | Registers the new GET route for the availability endpoint |
| tests/api/test_store.py | Comprehensive test suite covering success cases and various failure scenarios for the availability API |
mdegat01
force-pushed
the
add-addon-availability-api
branch
from
b59ab70 to
ad50498
Compare
|
@agners Reworked error to support specifying a key, message template and extra fields so we can make errors that are much more translation and client library friendly. Leveraged that for this work but this will require a pretty significant re-review and refactor of most of the errors in Supervisor going forward. As many should adopt this model. |
agners
left a comment
agners
left a comment
There was a problem hiding this comment.
This makes our error handling much more translation friendly: The key can be used to look up translations, and since we now pass parameters as separate fields the messages can easily formatted on client side without the need to parse and reformat our pre-processed messages. This makes any key plus extra field combination part of the API, as in if we want to change fields in an error we need to introduce a new key.
|
Does a Supervisor API user need to check the availability of an add-on before updating it? I'd expect that would happen automatically so no extra API call would be needed. |
The problem is backups: If we simply raise an error on the actual update attempt, then the caller might already have created a backup. At least for the update flows under control by the hassio integration this will allow to first check availability, before taking a backup. There is some more discussion in home-assistant/core#148954. |
|
Ok, that's good. I'd still expect the update call to raise an (the same) exception for an unavailable add-on. |
|
@MartinHjelmare Good point. I believe it does because both call the same method but i'll also add the same test cases there to make sure. |
mdegat01
force-pushed
the
add-addon-availability-api
branch
from
ad50498 to
64c4fb7
Compare
Proposed change
Add API that determines availability of an add-on for the current system. It always checks against the latest version in the store so it can be used to check availability prior to an update of an existing add-on or install of a new one.
Type of change
Additional information
Checklist
ruff format supervisor tests)If API endpoints or add-on configuration are added/changed: